Subject: Re: Working Group Last Call

From: Bala Rajagopalan <[email-masked]>
Date: Mon, 05 Jan 1998 16:05:02 -0500

Masataka Ohta wrote:

> 
> As has been mentioned in the last two meetings, a QoSR algorithm
> presented in the second QoSR BOF is now described in an INET'97
> paper:
> 
>         Yukinori Goto, Masataka Ohta, Keijiro Araki, "Path QoS Collection
>         for Stable Hop-by-Hop QoS Routing", Proceedings of INET'97,
>         http://www.isoc.org/isoc/whatis/conferences/inet/97/proceedings/F4/F4_2.HTM,
>         June 1997.
> 
> As you can see in the paper, the simple algorithm makes all the so
> called problem in the framework document is not a problem at all.

I don't see this at all. First of all, the only contribution of this
paper is to replace resource allocation routing updates with updates
that are carried in path messages. From the paper, it's not
clear to me how this mechanism ensures that a router knows
resource allocation for a flow on a remote branch of a multicast
tree. Even if this works, I don't see how this solves
the myriad of problems outlined in the framework draft. 

-----------
Bala Rajagopalan
NEC USA, C&C Research Labs
4 Independence Way
Princeton, NJ 08540
U.S.A

Ph: +1-609-951-2969
Fax: +1-609-951-2499
Email: [email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 6 Jan 98 18:05:20 JST

Bala;

> that are carried in path messages.

In a sense, you are right.

But, the replacement is essential to the scalability.

The problem of QoSR is that per-flow information can not be
scalably flooded.

But, RSVP PATH or RESV message is the transport over which per-flow
information can be scalably carried. As you might know, RSVP scales.

> From the paper, it's not
> tree.

Again, you are right on the understanding on our paper.

With Path QoS Collection, routers knows corrected resource allocation
for a flow on a upstream branch upto the multicast (or unicast)
source, which is just enough for hop-by-hop QoSR route determination.

> Even if this works, I don't see how this solves

It is partly because you think routers must have complete knowledge
of resource consumption over the entire multicast tree.

As our paper and your draft descibe, such an approach does not
scale but, fortunately, is unnecessary.

If you disagree, please specify which problem of you I haven't
solved yet?

The other unnecessary assumption of you is that you require flow
aggregation, which is, at least, very difficult and may be
impossible, to partially (but not fully, as your draft admits)
solves some scalability problem.

But, as hop-by-hop QoS routing with Path QoS Collection scales
as well as RSVP without flow aggregation, we don't have to worry
about how to archieve the impossible aggregation.

Note that our paper does assume link state aggregation, which is
different from flow aggregation.

Note also that I already made an presentation of an algorithm
for scalable link state aggregation in some QoSR meeting, though
I have not wrote a paper on it.

							Masataka Ohta